A database is a collection of stored data that is logically related and that is accessible by one or more users or applications. A popular type of database is the relational database management system (RDBMS), which includes relational tables, also referred to as relations, made up of rows and columns (also referred to as tuples and attributes). Each row represents an occurrence of an entity defined by a table, with an entity being a person, place, thing, or other object about which the table contains information.
One of the goals of a database management system is to optimize the performance of queries for access and manipulation of data stored in the database. Given a target environment, an optimal query plan is selected, with the optimal query plan being the one with the lowest cost, e.g., response time, as determined by an optimizer. The response time is the amount of time it takes to complete the execution of a query on a given system.
In managing resource usage of a database management system to meet either subject-area resource distribution, e.g., by country, application or division, or category-of-work resource distribution, e.g., high vs. low priority, priority scheduling technologies have proven somewhat effective. However, when the goal is to manage resource distribution both by subject-area and category-of-work coincident with each other, and/or when the number of subject areas becomes too large or disparate, modern priority scheduling technologies have proven ineffective.
Further, when the goal is subject area resource distribution, the granularity of time to manage within is often in conflict with priority scheduling sub-system granularities. For example, a priority scheduler may properly distribute resources to concurrent requests within a small, e.g., 60 second time interval, but when the desire is to manage resource distribution within a larger time slice, such as 1 hour or 1 day, contemporary priority schedulers are incapable of managing to that level of granularity.
As an example, consider a particular database system that is shared between 100 enterprise divisions. Each division funds the cost of a respective portion of the system. In many scenarios, each division may fund a different portion of the database system. For example, one large division may fund 30% of the system, while a very small division may only fund 0.1% of the system. Because each division has funded a respective portion of the system, a system management goal may be to enforce division access to the system when the demand arises. When a particular division does not impose demand to the system, that division's resources should become available to the remaining divisions so as not to waste system resources. However, if the division subsequently begins submitting requests to the system, not only should that division be assured access to the resources within the current priority scheduler time interval, but also priority over other unused division resources in the time slices to follow until the division's share of resources are provided within the larger time interval. The relative policies of current priority schedulers are incapable of managing such a scenario for two key reasons. First, priority schedulers only manage resources within a small time interval. Further, contemporary priority schedulers are incapable of fairly managing a large number of divisions or other entities that may contend for system resources, particularly when the weights, or preferences, assigned to the contending entities vary widely.